Security Risks

This page provides an overview of the most important security vulnerabilities that an InstantView developer should avoid during development.

OS Command Injection

Scenario

This type of attack occurs when shell functions such as RunSystemShell, System, System2, Execute, Execute2, etc. are used with variables and not just string constants. The danger is that these variables may contain user input, either directly from current user input from the interface or from data stored in the database that the user has manipulated before.

By manipulating the command string the attacker could execute everything on the server for which the ClassiX instance has rights. This makes this type of attack one of the most serious attacks, so you have to be extremely careful when using such a command.

Countermeasures

Unfortunately, this attack cannot be prevented by the base system without losing the sense of the shell functions. The safest way would be if these shell functions did not exist and all tasks were done by normal method calls. Especially in connection with legacy systems there are cases, however, where the shell functions cannot be dispensed with.

From the basic side it would be recommendable to reduce these shell functions to a single function and to warn about the dangers of this function when parsing code in the development IDE.

Filtering against shell metacharacters such as [&, &&, |, ||, 0x0a, etc.] is not a recommended countermeasure, as experience shows that blacklist filtering can never be complete. You should not take any risks with such a serious vulnerability.

The only countermeasure is to allow only white lists, numbers or alphanumeric strings without spaces or special characters.

Query Injection

Scenario

This attack is better known as SQL injection. Since we do not execute SQL queries in ClassiX, we are protected against SQL injection attacks. However, the SQL-Injection attack could be partly transferred to the world of ClassiX and defined as a Query-Injection attack.

In ClassiX, query strings are only used for data queries using Find, FindExist, FindFirst, etc. Therefore it is not possible to manipulate the database directly by query strings containing malicious code. This is an essential difference to SQL injection. The only thing you can do, however, is to design the query strings in such a way that the query returns more objects than the user has rights to. By displaying such objects and by not checking the rights when changing a DB object you can indirectly change the DB objects by manipulated query strings.

This query injection attack is only possible if the IV developer does not use the "%s" parameters and composes the query strings himself by concatenation with other variables.

Countermeasures

The exclusive use of formatting syntax and the avoidance of simple concatenation of query strings with variables over which the user has direct or indirect control.

File Path Traversal

Scenario

This attack is possible in ClassiX in connection with instructions like OpenDocument, LoadFromFile, SaveToFile etc., and in principle cannot be prevented without the IV developer's attention. It is a matter of the attacker getting to another file to which he has no access right by manipulating a file name. This can be relevant for both reading and writing.

Instructions manipulating files must not blindly obtain their parameters from widgets that are manipulated directly or indirectly by the user. It would be fatal if the entire path were to be taken from the user's input, because then the user could access every drive and every file. Typically, however, a file name is "asked" for and this is combined with a path prefix, and this is where the attack comes about by the attacker using traversal characters such as "../" to bypass the path prefix.

Countermeasures

The user input must be set to "..." before concatenation. , "/" and "\" before concatenation. It would be even safer to use IV-File/Directory commands after concatenation to find out whether the concatenated path (i.e. the file) is in the correct directory (identical to the path prefix).